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METHOD AND APPARATUS FOR REPORTING THE STATUS OF WORK IN 

PROGRESS 

BACKGROUND OF THE INVENTION 

1. The present invention relates generally to electronic monitoring of the status 
of work in progress and more particularly to electronically reporting in real-time 
shipping readiness of a product being produced. 

2. In any business, delivery of product or services within the time expectations of 
the customer is necessary to be successful. Customers expect delivery of a product or 
service on or before the date delivery was requested and if the business is consistently 
not meeting customers' expectations, they risk losing the client to a competitor and a 
reduction in market share. For many products or services, if delivery is earlier than 
expected, the customer is happy as most customers appreciate delivery of goods or 
services at any time before the expected date of delivery. However, some products by 
their very nature i.e., perishable goods, need to be delivered on a specific date or 
within a very narrow time span defined by the customer, 

3. For example, for some products, a customer may need to prepare a space for 
installation of the to-be-delivered product and, as such, may require a specified 
amount of lead-time. Thus if the product is delivered too early, it may cause 
additional costs to the customer for storage or other requirements. Additionally, if the 
shipment is late, the customer may begin to suffer a loss for every hour or day that the 
newly prepared site sits empty, waiting for the arrival of the product to install. 

4. It is therefore desirable to reduce variation in shipping dates to within a 
defined span of time near or at the customer's requested date for shipment. An 
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automated communication-reporting tool for managers trying to reduce variation in 
shipping dates would be highly desirable to support this task. 
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SUMMARY OF THE INVENTION 

5. The present invention discloses a method and system for electronically 
reporting real-time status of work in progress. An alert system is disclosed that 
contains both proactive and reactive alerts. The alert scheme is based upon the 
electronically warning of mismatched future promised delivery dates and customer 
requested shipping dates. The alerts assist with avoiding or greatly reducing any 
problems with meeting customer expectations. 

6. In accordance with one aspect of the invention, a method for reporting status 
of work in progress is disclosed wherein a database is periodically queried for 
information about product orders. The information obtained for each order includes: 
an order number, a promise date, a request date, a shipment date, and a product 
category for a plurality of products/services offered. The method further provides for 
comparing the promise dates and the request dates. When compared, it is decided 
whether an alert should be set, including setting a proactive promise alert if a promise 
date is later than a request date for a given order. The following step of this method 
includes displaying the proactive promise alerts with the order number, product 
category, and type of alert. 

7. In accordance with another aspect of the invention, a computer-readable 

medium is disclosed, having stored thereon one or more computer programs. The 

computer program(s), when executed by one or more computers, causes the one or 

more computers to display electronic shipment alerts. The program begins by 

instructing the one or more computers to populate a database with data to include an 

order number, a promise date, a request date, a shipment date, and a product category 

for a plurality of orders. The one or more computers are additionally instructed to 
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periodically query the database and compare promise dates to request dates. When 
compared, the one or more computers are instructed to set a proactive alert if the 
promise date is later than a request date, and set a reactive alert if the shipment date 
exists and the request date is less than a user-defined number of days prior to a current 
date. The one or more computers are then instructed to display any promise and 
shipment alerts by product category and type of alert. 

In accordance with yet another aspect of the invention, a computer data signal 
is disclosed, representing a sequence of instructions, that when executed by one of 
more processors, causes the one or more processors to display proactive and reactive 
alerts by product/service category and type of alert. The sequence of instructions first 
causes the one or more processors to populate a database with an order date indicating 
a date an order is initially made, a request date indicating a date when a customer 
requests delivery of the order, a shipment date, when available, indicating a date when 
actual shipment will occur, and a product/service category for each order for a 
product^service. The one or more processors are further instructed to query the 
database and compare promise dates to request dates for each order, and to check for 
the entry of a shipment date for each order. The one or more processors are then 
instructed to set a proactive alert if any promise date is later than a request date, and to 
set a reactive alert if a shipment date exists for an order and the request date is less 
than a user-defined number of days prior to a current date. The one or more processes 
are lastly instructed to display all proactive and reactive alerts by product/service 
category and type of alert. 

Various other features, objects, and advantages of the present invention are 

made apparent by the following detailed description and drawings. 

4 

EL662663465US 



Docket No. 15-EC-5776 

BRIEF DESCRIPTION OF THE DRAWINGS 

10. The drawings illustrate one preferred embodiment presently contemplated for 
carrying out the invention. 

In the drawings: 

1 1 . Fig. 1 is a high-level overview block diagram representing an embodiment of 
the invention. 

12. Fig. 2 is a flow chart representation of a process to display quality indicators 
in accordance with one aspect of the invention. 

1 3. Fig. 3 is a flow chart representation of the availability reporting process in 
accordance with another aspect of the invention. 

14. Fig. 4 is a flow chart representation of the work in progress table update 
process in accordance with another aspect of the invention. 

1 5. Fig. 5 is a flow chart representation of the shipment and promise alert setting 
and display process in accordance with another aspect of the invention. 

1 6. Fig. 6 is a flow chart representation of the process to display orders and 
revenue in accordance with another aspect of the invention. 

17. Fig. 7 is a representation of the Z-value graphic indicator in accordance with 
another aspect of the invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

18. In a preferred embodiment of the present invention, a program is designed to 
augment a commercially available database program. Specifically, it is designed as a 
separate program that works with data in the database. The program provides real- 
time, or near real-time reporting capabilities that are not available to users of the 
commercially available database. Other embodiments of the invention may use 
different hardware and/or software manifestations to embody the invention in 
accordance with their particular design. 

19. Referring to Fig. I , an overview diagram of a reporting system is shown which 
includes a plurality of user stations 10 such as User A, User B through User Z. These 
user stations 10 represent any number of users on a network at any time. The user 
stations 10 are connected to an Intranet server 12. This can be through direct 
communication, a local area network, or from another network like an intranet or the 
Internet. It may also include user stations 10 connected via a variety of other 
networking connections, including wireless connections. The Internet server 12 is in 
communication with database 1 4, which may be on another computer network. The 
Intranet server 12 is also communicatively connected to a mainframe/processing 
section 16. The Mainframe/ Processing section 16 processes data from database 14 
based on user requests and completes various reports and provides the reports to the 
user stations 10. 

20. Database 14 contains data on orders, availability (when products will be 

available for shipping), requested shipping dates, actual shipping dates, promised 

shipping dates, revenue per order, and various other product and sales information. 

All of the information is constantly updated at the user stations 10, and is 
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communicated through the Intranet server 12. Some of the users may update the 
information and some may merely be accessing the database for information. The 
boxes 20-28 in Fig 1 show the input of this information into the database 14, indicated 
by data input 18. The data includes new orders 20, update order status 22, current 
inventory 24, product status 26, and shipment data 28. 

2L The database 14 has the ability to reserve areas for computational results 

known as temporary tables 30. The tables contain the latest totals programmed to be 
stored therein that can be readily accessed by the users at user stations 10. It is 
temporary in that the temporary table processing system 32 repeatedly updates the 
temporary tables 30. When the data in the database 14 changes, the inputs to the 
temporary table processing system 32 are modified to update the information in the 
temporary tables 30 with new totals. In the preferred embodiment, the temporary 
table processing system 32 updates the data in the temporary tables 30 every 60 
minutes, but the time interval can be set by the programmer. Depending on needs, the 
update is performed based on such factors as product turn over, product manufacture 
time, number of orders taken per interval, and so on. The update should be performed 
often enough so that users acquire real-time data based on these factors. 

22. The preferred embodiment shown in Fig. 1 contemplates a manufacturing 

facility that has a number of products in various stages of completion, or a re- 
manufacturing facility with the same traits. Such a facility may have a system as 
represented by Fig. 1 merely to report the status to internal users. Additionally, an 
organization with these capabilities may want to make the information available to 
field sales personal, or even directly to potential customers. 
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23. Fig. 2 is a representation of a preferred embodiment for the statistical 
prediction of future performance process. In general, a process can be measured for 
performance if certain specification limits are set to measure it. To do so, the system 
must determine how many times the process produces a defect, or an output, that does 
not conform to the specifications that were set, as compared to how many times it 
produces a non-defect, or a successful output, within a given number of opportunities. 
In this maimer, it is possible statistically to predict the output of a process by sampling 
performance of the process and analyzing that data. The process can then be assessed 
and adjusted to improve future performance as against the specification limits. 

24. Referring to Fig. 2, the flowchart provides a description of a preferred process 
for creating the statistical calculation to indicate quality. Overall, Fig. 2 is divided 
into two separate parts. Part A describes updating the temporary tables 30 in the 
database 14, and Part B describes the process flow of the statistical calculation. 

25. Referring to Fig. 2, Part A, in more detail, upon initialization of the updating 

process 34, data from the database 36 is obtained by a fetch order for information 38. 

This is sometimes referred to as querying the database. In this embodiment, the data 

obtained is only for the orders that have occurred within the past year for statistical 

purposes. However, any time period can be chose based on design choice. The next 

step is where orders that have not been shipped are removed from consideration 40 

because this portion of the system is only concerned with shipped orders. Next, the 

initial calculation 42 is performed which requires fetching the maximum ship date 

from that order at 44 and fetching the customer's requested date for delivery 46. In 

this embodiment, each order may have more than one product, and the maximum ship 

date referred to in 44 is the date that the last product on the order was actually 
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shipped. The customer requested date for dehvery 46 is subtracted 48 from the 

maximum ship date 44. At this point, the process adds 52 the time needed for 

shipping the product to the customer 50 to the difference between the maximum ship 

date and the customer's requested date for delivery providing the resuU to update the 

table 54. Updating the information that is already in the table or providing a new 

entry then modifies the table. The process then checks whether the last order was 

processed 56, and if not 56a, the process returns to the initial calculation step 42 

where the previously-described process is repeated on the next order entry. If the 

order is the last 56b, then the process continues to the statistical calculation section of 

part B. It is important to note that the invention anticipates the use of any number of 

statistical calculations to predict the capability of a process, both known and as yet 

unknown. The preferred embodiment uses a value known as the "Z" score to provide 

information about process capability. 

26. To calculate the mean 58, the data is added together and divided by the 

number of entries. In statistical equations the mean is customarily represented by the 

Greek letter mu (fa). The next act in the process is to calculate the variance 60. As is 

well known in the art, this is done by subtracting the mean from each entry in the 

table to determine a deviation for each entry, squaring each deviation, summing the 

squared deviations and dividing that sum by the number of entries. The Greek letter 

sigma a represents variance when shown with an exponent of 2 (i.e., a^). The next 

act is to calculate the standard deviation 62. This calculation is also well known in 

the art, and it is equal to the square root of the variance. The standard deviation is 

traditionally represented by the Greek letter sigma (o) with an exponent of 1 . The 

next step is to determine the values for Z long-term and Z short-term 64. In general, 
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Z-scores are well known in the art of statistics. Z long-term (Zlt) is calculated from 
the standard deviation and the average output of the current process. Used with 
continuous data, Zlt represents the overall process capability and can be used to 
deterrnine the probability of out-of-specification parts within the current process. 
Usually process capability is measured in defective parts per million opportunities, or 
DPMO- 

27. In the preferred embodiment, the Z score is determined by first setting an 

upper specification limit (USL) and a lower specification limit (LSL), also referred to 
as tolerance limits. These limits are designated either arbitrarily, or as a result of 
researching customer needs, to determine the goals or tolerance of the process. As a 
measure of quality, any data point that falls outside of the USL and LSL is then 
considered a defect. The Z long-term (Zlt) value is then calculated by use of the 

formula: Zlt = min[^^^ — ii^ii — ^ where USL is the preset upper specification 
a (7 

limit, LSL is the preset lower specification limit, \x is the mean, and a is the standard 
deviation. In the preferred embodiment, the minimum result of the two expressions is 
taken as the measure of performance for the process. The user may then interpret the 
result. Interpretation may include applying the result to a normal or otiier distribution 
to determine the percentage of defects produced with a given number of opportunities. 
It is contemplated and believed within the scope of the present invention that 
interpretation of the results to determine DPMO could be easily automated as well. Z 
values can also be calculated in other ways; for example, both expressions can be 
used in some calculations instead of using the minimum of the two. 
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28. Continuing with the preferred embodiment, the Zlt value is then used to 
determine the Z short term (Zsx) value by using the formula: Zst Zlt + 1 -5. This is 
an estimation of performance based upon the idea that the performance of a process 
will deteriorate over time. Thus the short-term performance represented by the Z 
score should be better than the long-term performance, and adding 1.5 to the long- 
term Z score estimates the short-term Z score. The Z scores are then moved to the 
update table 66 where they can be called for display. In the preferred embodiment, Z 
short term (Zsx) is the standard scale for reporting performance quality based on a 
target goal of 6 Sigma (If Zst = 6 then DPMO = 3.4). At this point the process ends 
68. 

29. Accordingly, the present invention includes a method for measuring product 
shipment process capability that includes maintaining a database having therein data 
fields indicative of at least an order, a maximum ship date, a customer requested data, 
and a product categoty for each order, and then fetching order information for all 
orders that have a valid maximum ship date. The method includes subtracting the 
customer requested date from the maximum ship date and producing a difference 
value therefrom. Next, a predetermined number of days is added to the difference 
value to provide a shipment quality metric for each order. The method next includes 

using the shipment quality metric in a statistical calculation to indicate process 

) 

quality. 

30. In a preferred embodiment, the order information fetched from the database is 

only for those orders that were placed within a given time period. The statistical 

calculation can include determining a value for an upper specification limit and a 

lower specification limit, and then displaying the percentage of times the shipment 
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quality metric was greater than the upper specification limit and displaying the 
percentage of time the shipment quality metric was less than the lower specification 
limit. The invention can include setting a value for at least one specification limit and 
computing and displaying a statistical score based upon the specification limit and the 
shipment quality metrics where the statistical score is a measure of process capability. 
The process includes periodically repeating the fetching, subtracting, adding shipping 
days, and determining a statistical calculation at regular time intervals. The statistical 
calculation is preferably calculated and displayed for each product category. Further, 
the Z values can be displayed on a scale representing a range of Z values with an 
overlapping needle to indicate current performance as shown in Fig, 7. 

3 1 . The invention also includes a computer program implementing the 
aforementioned method. The computer program is stored on a computer readable 
medium and causes one or more computers to query a database that contains the 
information detailing orders, a requested delivery date, a maximum ship date, and a 
product category for a number of products. In processing the data, the computers are 
caused to ignore orders with no maximum ship date, and subtract the requested 
delivery date from the maximum ship date and add an adjustment value to obtain a 
shipment quality metric. The query, subtraction, and addition acts are repeated for the 
number of shipped products, and the computer program has instructions to process the 
shipment quality metrics to determine overall shipment quality, 

32. Preferably, the shipment quality metrics are processed to provide a statistical 
measure of process capability and are regularly reprocessed by repeating the 
aforementioned acts at regular time intervals. The regular time intervals are 
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dependent upon the system being evaluated and are preferably set such that the user of 
the system perceives that the shipment quality metrics are updated in real-time. 

33. Preferably, the set of instructions in the computer program that process the 
shipment quality metrics includes instructions to determine a mean and a standard 
deviation of the shipment quality metrics, and to designate an upper and lower 
specification limits, and then to determine a Z long-term value by subtracting the 
mean from the upper specification limit and dividing the result by the standard 
deviation. The Z long-term value is then displayed. Further instructions can includes 
an estimated value for Z short-term by adding a constant to the Z long-term value. 

34. Another embodiment of the invention includes a computer data signal 

representing a sequence of instructions that, when executed by a processor, cause the 

processor to maintain a database of data having therein an order number, a promise 

date, a request date, a maximum ship date, and a product category for each product. 

The instructions in the computer data signal cause the processor to obtain the data 

from each order that has a valid maximum ship date and create an upper specification 

limit by adding a predetermined number of days just prior to a customer's requested 

delivery date and to create a lower specification limit by adding a predetermined 

number of days after a customer's requested delivery date. The processor is then 

caused to compute and display a statistical value providing an indication of process 

capability. These instructions are periodically repeated either at regular time 

intervals, in real-time, or on a on-demand basis that can include recalculating the 

statistical value each time a user requests the information. In order to calculate the 

statistical value, the computer data signal preferably has instructions to determine a 

mean value and a standard deviation and to subtract the mean value from the upper 
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specification limit and divide a result by the standard deviation to create a first Z- 
value. The lower specification limit is subtracted from the mean value and the result 
is divided by the standard deviation to create a second Z- value. The minimum of the 
two values is then chosen as the statistical value. 

35. The computer data signal can also have instractions to project what the 
number of defects would be, given one million opportunities. The defects per million 
(DPM) is based upon a normal distribution. Applying the Zlt or Zst to a normal 
distribution table provides the predicted DPM. While the current preferred 
embodiment does not describe a method to do this electronically, it can easily be done 
by the use of a simple look-up table, well known in the art of computer programming. 
The Zlt or Zst value is found on the table and the associated DPM value is obtained. 
The DPM value is then displayed as the number of defects per one million 
opportunities. The instructions in the computer data signal can also cause a processor 
to decide which of the first and second Z-values are a minimum value and then to 
display the minimum value identified as a Z long-term value. A constant can then be 
added to the Z long-term value to determine and display a Z short-term value. 

36. Fig. 3 is a flow diagram of the process of a preferred embodiment for 

displaying inventory availability. The process begins at the start step 70 and the first 

step is to fetch all saleable items in the inventory 72 from the database. The program 

then must determine whether each record contains a date indicative of whether the 

product is available to ship, referred to as an available to promise (ATP) date 74. If a 

particular record does not have an ATP date 74a, the record is ignored 76. If it does 

have an ATP date 74b, then the process next counts the number of days between a 

current date (i.e., typically today) and the ATP date at 78. The resulting number is 
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then provided to the next part of the process to determine which of the messages is 
appropriate to display for this record. If the number of days between the current date 
and the ATP date is greater than 500 days 80, then the message "Call for Availability'^ 
is displayed 82. If the number of days between the current date and the ATP date is 
greater than 2 days and less than or equal to 500 days 84, then the message "Shipment 
within number where number is the number of days between the current date today 
and the ATP date days" 86 is displayed. On the other hand, if the number of days 
between the current date today and the ATP date is less than or equal to two 88, then 
the message "Immediate Shipment'' is displayed 90. Once the appropriate message is 
displayed, the process ends for that entry at 92. 

Fig. 4 is a flow diagram representing the work in progress (WIP) table update 
process for one preferred embodiment. The process updates the WIP table that is in 
the temporary tables of the database to ensure the data displayed is the most current 
available. The process begins after initialization 93 by fetching the booked orders that 
have been promised a shipping date 94. The system then determines whether the 
record, already exists in the current WIP table 96. If the record already exists 96a, the 
order number, order promise date, request date, and the product category are fetched 
98, and they are used to update the current entry in the WIP table 100. This portion of 
the process is then complete at 101 . If the record does not exist 96b, the order 
number, order promise date, request date, and the product category are fetched 102, 
and are used to create a new entry in the WIP table 104. This portion of the process is 
then complete at 101. The entire process repeats until all the entries for the WIP table 
have been either updated or created. 
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38. Fig. 5 is a flow chart representing the alert setting and display process. The 
system provides for both proactive and reactive alerts, allowing use of the information 
to repair problems in the shipping process. The word "proactive" is meant to show 
that an alert may be set while there is still time to rectify a possible problem in the 
process, in this case, shipping. The proactive alert allows the process owners to make 
adjustments or take special action in order to avoid a late shipment. The reactive alert 
may not provide the same information, but the information is still useful to ensure that 
recognized problems do not occur. 

39. Continuing with Fig. 5, the alert setting and display process begins after an 
initialization 105, by fetching the WIP table 106 and then processing with each order 
in the WIP table. The program fetches the respective product category 108 and then 
the maximum promise date 110. The maximum promise date is the latest date 
promised to the customer for shipment. The request date is then fetched 1 12, and then 
the process determines whether the promise date is after the request date 114. If the 
promise date is later than the request date 1 14a, then a "Promise Alert" is set and 
displayed for that order 116, and the process moves to the order already shipped 
question 118. If the maximum promise date is prior to the request date 1 14b, then the 
process skips the promise alert step 1 16 and moves directly to the order already 
shipped 1 18 determination. If the order has already been shipped 1 1 8a, the process 
moves directly to check to see if all the orders have been processed at 124. If not 

1 1 8b, the process then determines whether the request date is within a preset number 

of days from a current data 120. In this embodiment, the preset number of days is 

two. If the request date is not within two days of the current date 120a then the 

process moves to check if another order must be processed at 124. If the request date 
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is within two days of the current date 120b, then the "Ship Alert" is set and displayed 
122, and the process moves to check if all the orders have been processed 124. The 
process then repeats for all orders 124, 124a. Once all of the orders have been 
processed 124b, the alerts are accumulated and displayed for the individual orders 
sorted by product category and type of alert 126. The alerts provide opportunities for 
management to fix problems before they happen. 

40. Fig. 6 is a representation of the process used to display the orders and revenue 
for a past period of time. The process is initiated automatically when the information 
is requested, or on a regular pre-programmed basis 127. In a preferred embodiment, 
all of the order information, including revenue for each order, is retrieved from the 
database 128. The program then captures all the orders 130 in a previous period of 
time, in this example, a last year. The Orders table is then updated 132 with the data 
from the capture 130. At this point the orders in the table are sorted by month and 
category 134. The last step provides that the orders, order totals, revenue and revenue 
totals are displayed in tabular format 136 for viewing in an easily understandable way. 
After all the orders are displayed the process is completed at 138. 

41. In one aspect of the invention, a method for reporting status of work in 

progress is disclosed wherein a database is periodically queried for information about 

product orders. The information obtained for each order includes at least an order 

number, a promise date, a request date, a shipment date, and a product category for a 

plurality of products/services offered. The method further provides that one step 

conducts comparing the promise dates and the request dates to determine the 

difference. When compared, it is decided whether an alert should be set, including 

setting a proactive promise alert if a promise date is later than a request date for a 
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given order. The last step of the method displays the proactive promise alerts. This is 
formatted to make it easy to find the information needed. It can be displayed in table 
format with the order number, product category, and the type of alert. 

42. In accordance with another aspect of the invention, a computer-readable 
medium is disclosed, having stored thereon one or more computer programs. The 
computer program(s), when executed by one or more computers, causes the one or 
more computers to display electronic shipment alerts. The program begins by 
instructing the one or more computers to populate a database with data with at least 
the following for each order: an order number, a promise date, a request date, a 
shipment date, and a product category. The one or more computers are additionally 
instructed to periodically query the database and compare promise dates to request 
dates. The timing for automatically querying the database can be adjusted as 
necessary to provide up-to-date information. When the promise date is compared to 
the request date, the one or more computers are instructed to set a proactive alert if the 
promise date is later than a request date, and set a reactive alert if the shipment date 
exists and the request date is less than a user-defmed number of days prior to a current 
date. The one or more computers are then instructed to display any promise and 
shipment alerts by product category and type of alert. 

43. In accordance with yet another aspect of the invention, a computer data signal 

is disclosed. The signal represents a sequence of instructions that, when executed by 

one of more processors, cause the one or more processors to display proactive and 

reactive alerts by product/service category and type of alert. The sequence of 

instructions first cause the one or more processors to populate a database with at least: 

an order date indicating a date an order is initially made, a request date indicating a 
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date when a customer requests delivery of the order, a shipment date, when available, 
indicating a date when actual shipment will occur, and a product/service category for 
each order for a product/service. The one or more processors are further instructed to 
query the database and compare the promise date to the request date for each order, 
and to check for the entry of a shipment date for each order. The one or more 
processors are then instructed to set a proactive alert if any promise date is later than a 
request date» and to set a reactive alert if a shipment date exists for an order and the 
request date is less than a user-defined number of days prior to a current date. The 
one or more processes are lastly instructed to display all proactive and reactive alerts 
by product/service category and type of alert. 

44. Fig. 7 is a representation of the Z-value graphic indicator in accordance with 
another aspect of the invention. The preferred embodiment provides an indicator 
written in Java. The ranges of values on the scale change automatically to best reflect 
the value to be indicated, and the needle indicates the value of the current calculation. 

45. Each of the processes just described can be used alone, or in conjunction with 
each other in various combinations. In one preferred embodiment, the reports are 
displayed on a number of web pages within an intranet system. It is automatically 
updated and the information is available 24 hours a day on an as-needed, on-demand 
basis. 

46. The present invention has been described in terms of the preferred 
embodiment. While the preferred embodiment uses computers that are 
communicating through some form of a network, it is understood that other 
embodiments of the invention may involve the use of different technologies. It is 
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recognized that equivalents, alternatives and modifications that are different from the 
preferred embodiment exist, and they are within the scope of the appending claims. 
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